Arup Rakshit writes:
[...]
> Now you can see, that I have created, a new file called *file.txt*, in the
> *master branch*.
And here is your basic misunderstanding. You've created file.txt indeed,
but not in the *master branch* (or any branch). You've created it in the
working directory. Only
Hello,
Was writing conversion script from CVS to git for my repo and noticed
slight inconsistency in git-tag, git-branch, and git-update-ref behavior:
$ git --version
git version 1.9.3
$ git tag -d && echo success
success
$ git branch -d && echo success
fatal: branch name required
$ git update-re
Hello,
After convertion of a project from CVS to git, I'd like to rename some
references in the created git repository (before it's published, so no
problems here). Is there a plumbing that would do:
git rename-ref
for me?
For reference, the (ugly) solution I currrently use is:
# Renamve bra
John Keeping writes:
> On Fri, May 23, 2014 at 02:11:55PM +0400, Sergei Organov wrote:
>> Hello,
>>
>> After convertion of a project from CVS to git, I'd like to rename some
>> references in the created git repository (before it's published, so no
>&g
Hello,
Just playing with it, got some surprises:
$ git --version
git version 1.9.3
$ git describe --all
heads/v3.5
$ git describe --all --match 'v*'
tags/v3.5.6b2-4-gab4bf78
$ git describe --all --match 'heads/v*'
fatal: No names found, cannot describe anything.
... "heads/v3.5" matches neithe
Junio C Hamano writes:
> Sergei Organov writes:
>
>> Just playing with it, got some surprises:
>>
>> $ git --version
>> git version 1.9.3
>>
>> $ git describe --all
>> heads/v3.5
>> $ git describe --all --match 'v*'
>> tags/v
Junio C Hamano writes:
> Sergei Organov writes:
>
>> Will something break if it won't helpfully prepend refs/tags/ once
>> --all is given?
>
> "describe --all --match 'v*'" will no longer match a tag v1.2.3, and
> forces the users to say "
Hello,
$ git --version
git version 1.9.3
Please consider the following history:
--C--
/ \
/ M topic,HEAD
/ /
A---B master
shouldn't
$ git rebase master
be a no-op here? According to my reading of the rebase manual page, it
should be a no-op, as 'topic' is a descenda
Jonathan Nieder writes:
> Hi Sergei,
>
> Sergei Organov wrote:
>
>> --C--
>> / \
>>/ M topic,HEAD
>> / /
>> A---B master
>>
>> shouldn't
>>
>> $ git rebase master
>>
>> be a no-op her
Jonathan Nieder writes:
> David Besen wrote:
>> Jonathan Nieder wrote:
>
>>> This is how pull --rebase works. It turns your single-parent commits
>>> into a sequence of patches on top of upstream and completely ignores
>>> your merge commits.
>>>
>>> There is a --rebase=preserve option that make
Jonathan Nieder writes:
> Sergei Organov wrote:
>
>> Is there any scenario at all where pull --rebase=true wins over
>> preserve?
>
> Basically always in my book. ;-)
>
> When people turn on 'pull --rebase', they are asking for a clean,
> simplified his
Nico Williams writes:
> On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder wrote:
>> Sergei Organov wrote:
>>
>>> Is there any scenario at all where pull --rebase=true wins over
>>> preserve?
>>
>> Basically always in my book. ;-)
>>
>> W
Nico Williams writes:
> On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote:
>> Nico Williams writes:
>>> That exception aside, keeping all local commits "on top" by always
>>> rebasing them onto the upstream is extremely useful: a) in simplifying
>&
Nico Williams writes:
> On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov wrote:
>> Nico Williams writes:
>>> Local merge commits mean that you either didn't rebase to keep all
>>> your local commits on top of the upstream, or that you have multiple
>>>
14 matches
Mail list logo
