brian m. carlson sand...@crustytoothpaste.net writes:
On Wed, Jun 10, 2015 at 11:51:14PM +, brian m. carlson wrote:
On Wed, Jun 10, 2015 at 03:50:32PM -0700, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
Convert struct object to object_id
It seems
On 05/06, Johannes Löthberg wrote:
Each ref namespace have their own separate branches, tags, and HEAD, so
when pushing to a namespace we need to make sure that there exists a
HEAD ref for the namespace, otherwise you will not be able to check out
the repo after cloning from a namespace
On Wed, Jun 10, 2015 at 11:51:14PM +, brian m. carlson wrote:
On Wed, Jun 10, 2015 at 03:50:32PM -0700, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
Convert struct object to object_id
It seems that the last one didn't make it...
It appears the
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Somehow we are getting quite a many new topics in the past few
weeks. All the new contributors we acquired recently, including but
not limited
On Wed, Jun 10, 2015 at 03:50:32PM -0700, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
Convert struct object to object_id
It seems that the last one didn't make it...
It appears the mail was too large for vger. Unfortunately for
bisectability reasons, it is
A config option 'rebase.instructionFormat' can override the
default 'oneline' format of the rebase instruction list.
Since the list is parsed using the left, right or boundary mark plus
the sha1, they are prepended to the instruction format.
Signed-off-by: Michael Rappazzo rappa...@gmail.com
---
It can be useful to have grafts or replace refs for specific use-cases while
keeping the default view of the repository pristine (or with a different
set of grafts/replace refs).
It is possible to use a different graft file with GIT_GRAFT_FILE, but while
replace refs are more powerful, they don't
Difference between v2 and v3 of this patch:
- Fixed autosquash
- Added documentation on the config options
- Added two tests to t3414 (rebase-autosquash)
Michael Rappazzo (1):
git-rebase--interactive.sh: add config option for custom instruction
format
Mike Hommey m...@glandium.org writes:
It can be useful to have grafts or replace refs for specific use-cases while
keeping the default view of the repository pristine (or with a different
set of grafts/replace refs).
It is possible to use a different graft file with GIT_GRAFT_FILE, but while
On Wed, Jun 10, 2015 at 09:55:30PM -0700, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
It can be useful to have grafts or replace refs for specific
use-cases while keeping the default view of the repository
pristine (or with a different set of grafts/replace refs).
It
On Wed, Jun 10, 2015 at 05:21:33PM -0700, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
[0] https://github.com/bk2204/git.git object-id-part2
No approach other than just letting reviewers fetch from there and
taking a look is reasonable, I would think.
Did
Matthieu Moy matthieu@grenoble-inp.fr writes:
Louis-Alexandre Stuber stub...@ensimag.grenoble-inp.fr writes:
That is very different from ENOENT, which is an expected error when
you are not using a customized terms.
But in the current state, we are going to create bisect_terms even if
On Wed, Jun 10, 2015 at 10:38 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Paul Tan pyoka...@gmail.com writes:
@@ -422,6 +423,14 @@ int cmd_pull(int argc, const char **argv, const char
*prefix)
parse_repo_refspecs(argc, argv, repo, refspecs);
'restore' may be more consistent with git's internal terminology.
But from an outsider's perspective, 'revert' rather than 'restore' is in my
view much clearer and more consistent with other version control systems:
for example 'svn revert' is what you use to revert files in the working copy.
The
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr writes:
I agree, I'd like to put it right after split_at_commas in a separate
function trim_list. Is it a good idea even if the function is one
line long ?
Hmph, if I have A, B, C and call a function that gives an array of
addresses,
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr writes:
From: Jorge Juan Garcia Garcia jorge-juan.garcia-gar...@ensimag.imag.fr
Accept a list of emails separated by commas in flags --cc, --to and
--bcc. Multiple addresses can already be given by using these options
multiple times, but
Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
+# from the todolist in stdin
+check_bad_cmd_and_sha () {
+ git stripspace --strip-comments |
+ while read -r command sha1 rest
+ do
+ case $command in
+ ''|noop|x|exec)
+
Bob Bell b_...@thebellsplace.com writes:
Is this a proper solution, or did I just luck out? Am I perhaps
doing something foolish?
Yes, we happen to run checkout in the index order, but that is not
something we guarantee, so you can call yourself lucky. You are
being doubly lucky that nobody
On Wed, Jun 10, 2015 at 12:47 AM, Fredrik Gustafsson iv...@iveqy.com wrote:
On Tue, Jun 09, 2015 at 10:19:43AM -0700, Stefan Beller wrote:
Just because Git allows distributed workflows, doesn't mean we
should only focus on being distributed IMHO.
The question for content not being mergable
Matthieu Moy matthieu@grenoble-inp.fr writes:
Somebody else did it like that is not a good justification. Especially
when the previous code was not merged: the code wasn't finished.
But I actually disagree with the fact that it was not the idea. The
point of having the terms in
101 - 120 of 120 matches
Mail list logo
