feature be accepted?
--
Damien Robert
not sure I understand what a no-op `git fetch` means exactly.
In the "git fetch; ; git pull" scenario,
after I do the real `git fetch` and want to merge/rebase the changes, how
would I prevent `git pull` to pull new commits that were pushed in between?
--
Damien Robert
>From Damien Robert, Mon 08 Apr 2019 at 16:53:40 (+0200) :
> > Others may have a better idea, but I do not immediately see any
> > solution better than inventing a new option to "git pull".
So here is a RFC patch that implements --no-fetch. (I am not sure about
the wor
epends on the state of the git repositories of previous tests rather
than creating the git repos from scratch (presumably for the sake of
speed), so I was afraid to break things. But I see that I can probably
reuse the repos from the test 'setupt for detecting upstreamed changes'.
So I'll try (when I have time...) to do a RFC implementation of a 'noop
fetch' approach. I first need to understand the source of fetch.c better,
in particular how to do something like store_updated_refs when we are doing
a noop fetch (so without using transports).
--
Damien Robert
http://www.normalesup.org/~robert/pro
ch in two, one
introducing `stat_push_info` in remote.c and the following one using it in
ref-filter.c
Damien Robert (1):
Fix %(push:track) in ref-filter
ref-filter.c| 7 ++--
remote.c| 78 +++--
remote.h| 2 ++
t/
so that the upstream branch is ahead by 2 while the push
branch is ahead by 1, this allow us to test that %(push:track) refer to
the correct branch.
This change the expected value of some following tests, so update them
too.
Signed-off-by: Damien Robert
---
ref-filter.c| 7
pple effects of the test changes, since I think we'll end up
> changing them again to make sure ":trackshort" is distinct.
There are now less impactful than before because the master branch in the
test refers to the same commit as before; there is just a new commit for the
'myf
ntainer could adjust them when he picks up the patch). But
> there are just enough that it's probably worth making his life easier
> with a v3.
> You can put my Reviewed-by on it, too. :)
Here it is:
>8
From: Damien Robert
Date: Tue, 16 Apr 2019 14:16:46 +0200
Subject: [PA
rent
branch.
- `git mystash info` gives informations about a stash.
So obviously not all of these would be good for inclusion into git, but
maybe some of them would be somewhat worth it. When I have the time I'll
try to write tests and send proper patches.
--
Damien Robert
--
To unsubscr
Felipe Contreras wrote in message
<5366db742d494_18f9e4b308aa@nysa.notmuch>:
> == git update ==
>
> Another proposed solution is to have a new command: `git update`. This
> command would be similar to `git pull --ff-only` by default, but it
> could be configured to do merges instead, and when doi
> A bot could subscribe to the list and create branches in a public repo.
> (This idea feels familiar -- didn't somebody attempt this already?)
Thomas Rast maintains git notes that link git commits to their gmane
discussion, you can get them with
[remote "mailnotes"]
url = git://github.com/tras
Matthieu Moy wrote in message :
>> that confuses users.
>
> ... but I do agree that the doc is really confusing. It would be much
> better if the doc could be reduced to:
>
> "This is a synonym for linkgit:git-log[1] --raw --some --other ---options.
> Please refer to the documentation of that co
Junio C Hamano wrote in message
<7v61vg9eht@alter.siamese.dyndns.org>:
> The "tutorial" was written in fairly early days of Git's history, in
> order to primarily help those who want to use the plumbing command
> to script their own Porcelain commands. As it says at the very
> beginning, the
git init
git commit --allow-empty -m "init"
git checkout -b test
echo foo > foo
git add foo
git commit -am 'add foo'
git checkout master
echo 'Important data' > foo #[1]
echo foo > .gitignore
git checkout test
If I tried a `git checkout test` after [1], I would get the error message
error: T
I would like to use git ls-files to show all the ignored files, including
directory.
As an example of setup:
mkdir /tmp/git && cd /tmp/git
git init
mkdir a b
touch a/a
touch b/b
cat >.gitignore << EOF
a/
b/*
EOF
Then if I do:
$ git ls-files --exclude-standard --ignored --others
b/b
$ git ls-file
ress robert@numenor.night-elves. I thought that putting:
Damien Robert
in the .mailmap would unify the two adresses, but it does not:
git shortlog -se
15 Damien Robert
266 Damien Robert
as you can see, the Damien.Olivier.Robert+git as been lowercased to
damien.olivier.robert, so I am forced
Hi all,
I was wondering if you had any tips on the following workflow:
I work on an experimental feature branch of a project. I have some patches
that I implement in branch patch1 and patch2 on top of the feature branch.
I test if they both work together by merging patch1 and patch2 into a build
br
17 matches
Mail list logo
