the careless committer and fear of commitment (rebase -i vs add -p)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Avery Pennarun wrote:

> I generally just make a temporary commit
> with "git commit", then revise it using "git commit --amend" over
> time.
> 
> Or else I make a series of commits, then *later* squash them all
> together using 'git merge --squash' or 'git rebase -i'.
> 
> It seems like the suggested feature would encourage people to do it
> the "wrong" way (not creating temporary commits, thus making it easy
> to make a mistake and blow things away) just because they aren't aware
> of the above options.
> 
> Is there a reason that these methods don't work for you?

I like ‘git diff --cached’ and ‘git diff’ to show the entire list
of staged and unstaged changes.  I don’t consider this “wrong” at all.
Generally, once something becomes precious enough to be worth keeping,
it is already in presentable form and I can come up with an appropriate
commit message.  I understand that other people work differently; this
is just my personal preference.

I also use the stash heavily, which maybe mitigates the “content could
be blown away with a simple rm -f” problem.

You might also be interested in Pasky’s analysis at
http://thread.gmane.org/gmane.comp.version-control.git/138641/focus=138672

Cheers,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]